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Summary 

Previous studies have shown that radio commu- 
nications between pilots and air traffic control con- 
tribute to high pilot work load and are subject to 
various errors. These errors are caused by conges- 
tion on the voice radio channel and result in missed 
and misunderstood messages. The use of digital data 
link has been proposed as a means of reducing the 
work load and error rate. A critical factor, however, 
in determining the potential benefit of data link will 
be the interface between future data-link systems and 
the operators of those systems, both in the air and on 
the ground. The purpose of this study was to eval- 
uate the pilot interface with various levels of data- 
link capability in simulated, general-aviation, single- 
pilot, instrument-ffight-rule operations. The study 
was conducted in a light, twin-engine-airplane simu- 
lator equipped with a motion base and an out-the- 
window visual scene. The scenarios included all 
flying, navigational, and communications tasks asso- 
ciated with arrival and departure operations. 

During the simulated flight operations, the data 
link reduced demands on the pilots’ short-term mem- 
ory, reduced the number of communication transmis- 
sions, and permitted the pilots to more easily al- 
locate time to critical cockpit tasks while receiving 
air-traffic-control messages. The pilots who partic- 
ipated in the study unanimously indicated a pref- 
erence for data-link communications over voice-only 
communications. There were, however, situations in 
which the pilots preferred the use of voice communi- 
cations. These situations included takeoff clearance, 
messages received with the airplane at a low altitude, 
and pilot requests for altitude or heading changes. A 
disadvantage of the data link was an increased time 
delay in the acknowledgment of messages to air traf- 
fic control, that was the result of a tendency of the 
pilots to delay the processing of data-link messages 
during high-work-load events. 

Introduction 

Prior research has shown general-aviation, single- 
pilot, instrument-flight-rule (IFR) operations to be 
very challenging for a pilot. Most tasks in termi- 
nal airspace are time-critical, and during periods of 
high work load the pilot may not be able to perform 
all tasks with the desired precision or cross-checking. 
The study described in reference 1 showed that when 
a copilot was introduced into flight operations and 
was allowed to perform only certain tasks for the pi- 
lot, the most beneficial task was communicating with 
air traffic control (ATC). An analysis of actual oper- 
ational problems (ref. 2), as reported to the Aviation 
Safety Reporting System, also showed ATC and pi- 


lot communications to be a major problem area in 
single-pilot IFR operations. These communication 
problems included misunderstood instructions, fre- 
quency congestion, and excessive frequency changes. 
These problems suggest that improvements in com- 
munications between pilots and ATC may reduce er- 
rors and increase the safety and utility of general- 
aviation aircraft. 

The use of digital data-link communications be- 
tween pilots and ATC has been proposed as a means 
of improving the communications link. Data link 
was previously evaluated in a simple general-aviation 
training simulator (ref. 3) with favorable results. An 
in-flight study of a simulated data-link capability was 
also conducted in a light, twin-engine airplane (refs. 4 
and 5), and comments from the pilots were generally 
favorable. The use of data link for air-carrier aircraft 
has also been proposed and studied (refs. 3 and 6). 
With the introduction of the discrete- address Mode-S 
transponder and proposals for other data-link chan- 
nels, such as satellite data link and radio links similar 
to the Arinc communications addressing and report- 
ing system (ACARS), data-link communications be- 
tween pilots and ATC have become feasible. A crit- 
ical factor in determining the utility and acceptance 
of data link will be the interface between future data- 
link systems and the operators of those systems, both 
in the air and on the ground. 

The purpose of this study was to evaluate the pi- 
lot interface with various levels of data-link capabil- 
ity in a realistic IFR environment. Determining the 
relative benefits of various levels of capability was 
desirable, since previous research (ref. 1) has shown 
simplicity of equipment operation to be an overriding 
consideration in single-pilot operations. This study 
was conducted in a general-aviation, light, twin- 
engine-airplane research simulator equipped with a 
motion base and an out-the-window visual scene. 
A simulation of an ATC facility was used to rep- 
resent the ATC environment in the vicinity of Den- 
ver, Colorado, during arrival and departure scenarios 
from Stapleton International Airport. The scenarios 
included all flying, navigational, and communications 
tasks associated with operations between the runway 
and en route cruise. For each data-link level, mea- 
surements were made of voice and data-link activity 
and of the time required for pilot response to ATC 
messages. Pilot acceptance and operational advan- 
tages and disadvantages of each data-link level were 
also determined. 

Abbreviations 

ABV above 



ACARS 

Arinc (Aeronautical Radio, 

ILS 

instrument landing system 


Incorporated) communications 
addressing and reporting 

INFO 

information 

ADF 

system 

automatic direction finder 

IOC 

three-letter identifier for 
KIOWA VORTAC 

ALT 

aircraft altitude, ft above 

KS 

Kansas 


mean sea level; also altimeter 

LOC 

ILS localizer 


setting, inches of mercury 

MIN 

minutes 

APPR 

approach 

MOD 

moderate 

ARR 

arrival 

MOTAS 

mission-oriented terminal-area 

ATC 

air traffic control 


simulation 

ATIS 

automatic terminal informa- 

MSG 

message 


tion service 

MTN 

maintain 

ATISA 

approach ATIS information 

N/A 

not applicable 

BACK SPC 

backspace 

NAV 

navigation 

BKN 

broken 

NDB 

nondirectional radio beacon 

CDI 

course-deviation indicator 

NE 

Nebraska 

CLRD 

cleared 

OCNL 

occasionally 

CLRNC DELIV 

clearance delivery 

OM 

ILS outer marker 

CO 

Colorado 

OVC 

overcast 

COMM 

communications 

PIREP 

pilot weather report 

CRT 

cathode ray tube 

REQ 

request 

DEN 

three-letter identifier for 

RWY.RWYS 

runway (s) 


Denver’s Stapleton Interna- 
tional Airport; also DENVER 

S 

standard deviation 

DEP 

DIR 

DME 

EXPT 

FAA 

VORTAC 

departure 

direct 

distance measuring equipment 
expect 

Federal Aviation 

SIGMET 

SVR 

TACAN 

TEMP 

TERM 

significant meteorological 
information 

severe 

tactical air navigation 
temperature, °F 
terminal 

FT 

Administration 

feet; also terminal forecast 

TWR 

TXC 

air-traffic-control tower (local 
controller) 

three-letter identifier for 

GA 

general aviation 


THURMAN VORTAC 

GLD 

HDG 

three-letter identifier for 
GOODLAND VORTAC 

aircraft heading from magnetic 

UA 

VIS 

pilot report 
visibility 


north, deg 

VLDS 

visual landing display system 

HSI 

horizontal situation indicator 

VOR 

very high frequency omni- 
directional radio range 

ICG 

icing 

VORTAC 

combined VOR and tactical 

IFR 

instrument flight rules 


air navigation 
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WILCO will comply 

WX weather 

Description of Equipment 

Airplane Simulation 

The Langley General Aviation Simulator was 
used in this study. The hardware consisted of a fully 
enclosed cockpit mounted on a two-degree-of-freedom 
motion-base platform. The motion base provided 
pitch and roll cues. The Langley Visual Landing 
Display System (VLDS) provided out-the-window vi- 
sual cues for taxi, takeoff, approach, and landing. A 
collimating lens focused the image at infinity, and 
various weather-ceiling and visibility conditions were 
simulated. The cockpit instrument panel was config- 
ured as a generic, general- aviation, multiengine air- 
plane (fig. 1). The instruments included a horizontal 
situation indicator (HSI), a course-deviation indica- 
tor (CDI), an automatic direction finder (ADF), and 
distance measuring equipment (DME). The avion- 
ics were representative of state-of-the-art equipment, 
with active and standby frequencies for all radios. 
This feature permitted the pilot to select the next fre- 
quency in the standby window during low-work-load 
periods and to activate that frequency when needed 
by pushing one button. The control yoke and rudder 
pedals in the simulator were hydraulically loaded to 
provide the appropriate force gradients with changes 
in airspeed and configuration. A sound system in the 
simulator cockpit provided engine- and wind-noise 
cues. The engine sound varied with engine speed, 
and the wind noise varied with airspeed. The simu- 
lator and VLDS were driven by a CYBER 175 digital 
computer. 

The simulator software modeled a Cessna 402B 
airplane. The model included wing-flap and landing- 
gear effects on airplane stability and performance, in- 
strument and engine lags, and an atmospheric wind 
model. No atmospheric turbulence was used in this 
study. A navigational data base, which simulated the 
environment in the area of Stapleton International 
Airport in Denver, Colorado, was used. The data 
base extended to the en route environment, about 
60 miles east of Denver, and included the instru- 
ment landing system (ILS), nondirectional radio bea- 
con (NDB), omnirange/TACAN (VORTAC), marker 
beacon, and DME facilities that were applicable to 
the scenarios defined for this study. 

Air-Traffic-Control Simulation 

The ATC simulation was provided by one individ- 
ual, assuming the role of all controllers and pseudo 


pilots, using an ATC station (fig. 2) located in the 
Langley Mission-Oriented Terminal- Area Simulation 
(MOTAS) Facility (ref. 7). Pseudo aircraft were sim- 
ple representations of aircraft accomplished by dis- 
playing the software-modeled aircraft on the con- 
troller’s display. The sole purpose of the pseudo 
aircraft was to provide realism to the subject pilot, 
in the form of audio communications between ATC 
and other aircraft. Voice communications between 
the subject pilot and the controller were achieved 
only when both were tuned to the same radio fre- 
quency. An automatic terminal information service 
(ATIS) message capability was provided with a tape 
player. The pilot could receive ATIS messages by 
tuning either communication radio to the ATIS fre- 
quency. The various ATIS messages used are shown 
in the appendix. A voice disguiser was used to permit 
one person to act as the ATC controller and pseudo 
pilots, and present to the subject pilot a different 
voice for each of those roles. The voice disguiser was 
manually set for each voice setting as required. 

The operational environment for the ATC simu- 
lation was the Stapleton International Airport and 
the surrounding terminal area. The terminal area, 
or approach-control airspace, was centered around 
the Stapleton International Airport and extended 
from the surface to 20000 ft. The airspace con- 
figuration included four arrival corridors; the areas 
separating the arrival corridors were used for depar- 
tures and are called departure gates. At Denver, the 
flow of arrivals is normally through the arrival corri- 
dors; however, in the case of light twin-engine and 
single-engine propeller-driven aircraft, low-altitude 
inbound routings through the departure gates are fre- 
quently used. These routings allow slower and faster 
traffic to merge closer to the airport, which produces 
a more efficient flow of traffic. During the simula- 
tions, the subject aircraft received inbound routings 
through both the arrival corridors and through the 
departure gates. 

Control instructions issued to the subject air- 
craft were similar to those actually used at Stapleton 
International Airport for arriving light commuter air- 
craft and general- aviation aircraft, including tech- 
niques commonly used to lessen the impact of slower 
aircraft on the traffic flow. Specific examples include 
requests to maintain the best possible speeds and 
vectors to join the final- approach course at the final- 
approach fix. 

During arrivals, the subject airplane encountered 
a total of five controllers: a center controller, two ap- 
proach controllers, a tower controller, and a ground 
controller. During departures, the airplane was han- 
dled by a ground controller, a tower controller, a de- 
parture controller, and a center controller. 
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Communications were provided between the ATC 
controller in the MOTAS facility and the pilot in the 
cockpit by both voice link and data link. The voice 
link consisted of a headset and push-to-talk switch for 
the pilot, communication radios and audio controls 
in the cockpit, and a voice line to the MOTAS 
facility. From the pilot’s point of view, the voice- 
system operation was nearly identical to the real- 
world environment. The cockpit audio panel allowed 
the pilot to select which of the two communications 
radios would be used for transmitting and which 
radios would be connected to the pilot’s earpiece or 
cabin speaker. Selecting the audio from a navigation 
receiver gave the morse-code identification for the 
selected station. The two communications radios 
had individual volume controls and were individually 
tuned. As in the real world, it was necessary for 
the pilot and the ATC controller to be on the same 
frequency for communications to take place. Unlike 
the real world, only one controller was present in the 
simulation, and the pilot was able to communicate 
only with the current control facility. 

Data-Link Simulation 

Data-link messages were presented to the pilot on 
a data-link panel (fig. 3) which was installed on the 
cockpit instrument panel immediately to the right of 
the flight instruments (fig. 1). A cathode ray tube 
video screen (CRT) was provided to display ATC 
and weather messages to the pilot, and a keyboard 
enabled the pilot to acknowledge ATC messages and 
down-link messages to ATC. Major components of 
the display format were an 8-line by 30-character 
text area in the center of the screen, for weather 
and ATC messages; two dedicated windows at the 
bottom of the screen, which showed the last assigned 
heading and altitude; and a scratch pad between the 
text area and the dedicated windows, for composing 
down-link messages. The up link of an ATC message 
was annunciated with a light located just above the 
attitude indicator and with an audio tone. New 
messages appeared in inverse video (black on a white 
background) until that message was acknowledged. 
The message then changed to normal video (white 
on a black background). In certain data-link runs, 
a small cockpit printer was available to the pilot. 
Pressing a button on the data-link panel caused the 
contents of the CRT to be printed. 

Four levels of communication capability were 
tested in this study. Level 1 was a baseline, voice- 
only communication capability. No data-link com- 
munications were possible. The voice communication 
capability was retained in all data-link levels. Level 2 
provided one-way data link, from the controller to the 
pilot, of heading and altitude to fly. One-way data 


link indicates that no messages could be sent over 
the data link by the pilot, except for acknowledg- 
ment of ATC messages. Only the dedicated windows 
at the bottom of the CRT were used, and no textual 
information was transmitted. Level 3 provided the 
capability of level 2, plus one-way data link of tex- 
tual information. The textual information was used 
for such tasks as initiating hand-offs, vectors, and ap- 
proach and landing clearances. Level 3 also included 
the use of the cockpit printer. Level 4 provided the 
capabilities of level 3 plus the capability of the pilot 
to send messages to ATC and to request weather in- 
formation on a separate weather page. The messages 
that could be sent to ATC were “Request clearance” 
for the initial IFR route clearance, “Request taxi,” 
“Request takeoff,” “Request altitude and “Re- 
quest heading .” The last two messages required 

the use of the numeric keys to enter the desired al- 
titude or heading. The weather page permitted the 
pilot to request arrival and departure automatic ter- 
minal information service (ATIS) information, pilot 
weather reports (PIREPS), significant meteorologi- 
cal information (SIGMET) advisories, and the local 
terminal forecast. The data-link levels are summa- 
rized as follows: 


Data-link 

level 

Data-link features 

1 

None (voice only) 

2 

Level 1 4* heading and altitude 

windows and acknowledgment 
down link 

3 

Level 2 + textual-data 
up link and printer 

4 

Level 3 + textual-data down 
link and weather page 


Detailed information on the implementation of the 
data-link simulation and the pilot and controller op- 
eration of the data link is presented in the appendix. 

Description of Task 

Several assumptions were made during the de- 
sign and performance of this study. The primary 
assumption was that the data link was intended to 
coexist with, not replace, the voice channel. This ar- 
rangement was intended to permit routine ATC com- 
munications, which encompass the majority of ATC 
transmissions, to be handled with a simple data-link 
interface. The voice channel remained available for 
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nonroutine communications. The protocol for data- 
link usage was designed to coexist with voice-link us- 
age. For example, a hand-off from one controller 
to another would begin with a data-link message 
such as “Contact DEN approach 119.45.” The pilot 
would use the data-link “YES” button to acknowl- 
edge the message and would then tune the commu- 
nication transceiver to the next controller frequency, 
119.45. Standard voice phraseology, such as “Den- 
ver approach, NASA 402 with you, 9000 ft,” would 
then be used to establish contact with the second 
controller. The second controller would acknowledge 
the voice transmission via voice and would then use 
the data link for later messages. The protocol was 
designed so that a listening watch would always be 
maintained with the current ATC controller. Data- 
link messages were acknowledged via the data-link 
and voice messages were acknowledged via voice. 

A second assumption was that the procedures in 
use in the ATC system of today (ref. 8) would ini- 
tially be used with data link. Although the use of 
data link for tactical messages is probably not possi- 
ble without significant ATC automation, the form of 
this automation is not known at present and could 
be transparent to the pilot. Present-day procedures 
were therefore used in this effort. For example, the 
pilot was required to inform the initial approach con- 
troller that the current ATIS information had been 
received and to provide controllers with the airplane 
altitude on the first voice contact. No advanced ATC 
procedures or automation were assumed, other than 
the presence of data link. It was further assumed 
that not all aircraft would be data-link equipped; the 
voice communications overheard by the subject pilot 
therefore included other aircraft. 

This effort was intended to be a study of the 
use of the data link in a general-aviation, single- 
pilot operation. Work load and the pilot interface 
with controls and displays are especially critical in 
this type of operation (ref. 1); therefore, no copilot 
was used, nor was the use of the simulator autopilot 
permitted. 

Arrival Scenarios 

The piloting task consisted of both arrival and 
departure scenarios. The arrival scenarios began 
with the simulated airplane about 30 n.mi. from 
Denver, in Denver Air Route Traffic Control Center 
(Denver Center) airspace. Four arrival scenarios, 
based on two basic arrival routes, were used. The 
four scenarios are depicted in figure 4. In the first 
arrival route (used for scenarios A1 and A2), the 
airplane was initialized on victor airway 4 (V4), at 
the BYERS intersection at an altitude of 12 000 ft on 
a heading to track the airway westbound. The pilot 


was told before the run, in this case, that the current 
clearance was to track V4 to the DENVER VORTAC 
at 12 000 ft. In the second arrival route (used for 
scenarios A3 and A4), the airplane was initialized on 
victor airway 148 (V148), 10 n.mi. northeast of the 
KIOWA VORTAC at an altitude of 12 000 ft on a 
heading to track the airway to KIOWA. The pilot 
was told before the run that the current clearance 
was to track V148 to KIOWA and victor airway 19 
(V19) to DENVER and to maintain 12 000 ft. 

The four arrival scenarios were used to prevent 
the pilots from knowing the vectors and altitudes to 
expect on each run; they are labeled A1 through A4. 
Scenario A1 used the first arrival route and involved 
an approach and landing on runway 35R. Scenario A2 
also used the first arrival route but used runway 26L 
for the landing. Scenario A3 used the second ar- 
rival route and terminated with a landing on run- 
way 26L. Scenario A4 also used the second arrival 
route but terminated with a landing on runway 35R. 
The length of each run was approximately 20 min, 
and the four arrival scenarios were considered equiv- 
alent for data analysis purposes. 

In each of the arrival scenarios, the pilot began 
the run under the control of Denver Center. The pilot 
was required to acquire the current ATIS information 
from Stapleton International Airport in anticipation 
of the hand-off from the Denver Center controller 
to a Denver Approach controller. After the hand- 
off to Denver Approach, the pilot began to receive 
altitude assignments and vectors to one of the two 
ILS approaches used in the study. The instrument 
approach charts for the approaches are shown in 
figures 5 and 6. The runs were terminated after the 
landing, while the airplane was still on the runway. 
During the vectoring operation, hand-offs to other 
controllers were accomplished as the airplane flew 
from one ATC sector to another. 

Departure Scenarios 

Three departure scenarios, based on two basic 
departure routes, were used. The three scenarios 
are depicted in figure 7. The pilot was told prior 
to the runs that a flight plan to Goodland, Kansas, 
had been filed with a requested cruising altitude of 
11 000 ft. This destination is approximately 150 n.mi. 
east of Denver, and the pertinent airways and navi- 
gation facilities are shown in figure 8. The flight-plan 
route was V4 to GOODLAND. The first departure 
route used was the flight-plan route. The other route 
was V19 to KIOWA, V148 to THURMAN, and V4 
to GOODLAND. Both runways, 26L and 35R, were 
used for departures in the V4 scenarios. Only runway 
26L was used in runs that involved the V19 depar- 
ture route. Therefore, there were three departure 
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scenarios, labeled D1 through D3. Scenario D1 used 
runway 35R for takeoff and used the V4 departure 
route. Scenario D2 began with a takeoff on runway 
26L and also used the V4 departure route. Scenario 
D3 also began on runway 26L, but the airplane used 
the second departure route. Each scenario required 
approximately 20 min and is considered equivalent 
to the others for data analysis purposes. 

The departure scenarios began with the airplane 
on the ground. The airplane was positioned on a 
taxiway at the entrance to the departure runway in 
use. After beginning the run, the pilot was required 
to obtain the current ATIS information and the IFR 
clearance to Goodland. The IFR clearance generally 
included climb restrictions rather than allowing an 
uninterrupted climb to the requested altitude. After 
accepting the clearance, the pilot contacted the tower 
and was cleared for takeoff. For added realism, the 
pilot was randomly given a direct takeoff clearance, 
was told to hold for landing traffic, or was told to 
taxi into position and hold. 

After takeoff, the pilot was given a hand-off from 
the tower to departure control and was provided with 
vectors to the airway. In the case of a departure 
to V4, the pilot was given vectors that paralleled 
the airway to the north. This procedure kept the 
departure path clear of the arrival flow to runway 
26L. The airplane altitude was restricted to 10 000 ft 
until after passing a routine flow of arrival traffic 
that departed the FLOTS intersection southbound. 
Once clear of the arrival traffic, the pilot was given 
a vector to intercept V4. In the vicinity of the 
BYERS intersection, the pilot intercepted V4, and 
was given a hand-off to Denver Center. The run 
terminated after the hand-off. In the case of a 
departure to V19, the pilot was vectored to the 
southeast of the airport and then given a clearance to 
either intercept V19 or to proceed direct to KIOWA. 
Shortly after passing the KIOWA VORTAC, the 
airplane was given a hand-off to Denver Center, and 
the run was terminated. In both runs, the airplane 
was given hand-offs to other controllers as it entered 
the various ATC sectors. 

Weather Conditions 

The VLDS system was used to provide ceiling and 
visibility limitations. Two basic weather conditions 
were used. One was a ceiling of 450 ft with a 
visibility of 2 mi. The second was a ceiling of 
700 ft with a visibility of 5 mi. The recorded ATIS 
information reflected these conditions with reported 
ceilings between 400 ft and 1000 ft. An additional 
condition with zero ceiling and zero visibility was 
used on one arrival run for each pilot to force a missed 
approach. When the airplane was above the ceiling 


set for each run, no visual scene was available out 
the simulator window. Below the ceiling, the outside 
world became visible. The wind in each run was from 
the northwest and was either 3 or 8 knots in any given 
scenario. No atmospheric turbulence was used in the 
simulation. 

Abnormal Situations 

Two aircraft abnormal situations were introduced 
in the simulation to evaluate the pilot acceptance 
of data link in those situations and to prevent the 
runs from becoming completely routine. The pilots 
were not told that any particular abnormal situa- 
tion would occur and were told to operate the sim- 
ulator as they would an actual airplane, during the 
scenarios, until the runs were terminated by the re- 
searcher. The abnormal-situation runs were consid- 
ered separately from the normal runs for data anal- 
ysis purposes. 

One abnormal situation, included in one of the 
arrival scenarios, involved a complete loss of voice 
communications during the hand-off from Denver 
Center to Denver Approach. This abnormal situation 
was only introduced with the two highest levels of 
data-link capability, levels 3 and 4. In these runs, 
normal communications took place until the pilot 
attempted to contact the first approach controller. 
From that time, the controller in the MOTAS facility 
ceased to call or respond to the pilot over the voice 
link, or to communicate with the pseudo aircraft. 
The remainder of the run was conducted with only 
the data link; ATC continued to send appropriate 
data-link instructions. 

The other abnormal situation involved a failed en- 
gine during a departure scenario. This abnormal sit- 
uation was also only introduced with the two high- 
est levels of data link. The departure scenario used 
was a runway 26L takeoff and vectors to parallel V4 
in preparation for joining V4 eastbound. Approx- 
imately 10 n.mi. northeast of the airport, in level 
cruise flight, the right engine was failed by simulating 
an idle throttle setting in software. The scenario was 
designed with the expectation that the pilot would 
respond to the engine failure and request a return to 
Denver for a landing. Air traffic control, upon being 
advised of the problem, made the standard requests 
for the number of people on board, fuel remaining, 
and the nature of any assistance required. After the 
pilot requested a return to Denver, the controller pro- 
vided vectors for an ILS approach to runway 26L. 
The run was terminated after landing. Although the 
pilot was expected to use the voice channel to report 
the situation and the ATC controller used voice for 
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acknowledgment and the initial questions, the sce- 
nario called for ATC to return to the data link for 
the remainder of the flight. 

In addition to the planned abnormal situations, 
several simulator hardware problems affected the 
runs. One problem involved the tuning of the avion- 
ics. The hardware that detected the movement of 
the rotary tuning knobs on the avionics panel would 
occasionally misread pilot input and would cause dif- 
ficulty in frequency setting. Since this problem had 
the potential to artificially increase pilot work load, 
the pilots were briefed on this difficulty and told that 
the researcher in the cockpit would assist in clearing 
the malfunction when requested. The pilot was re- 
quired to attempt to tune the radio in each case. 
A second problem involved the matching of the fre- 
quency tuned on the cockpit radio and the frequency 
on the frequency-select box in the MOTAS facility. 
Occasionally during a hand-off, the hardware would 
not detect that the pilot had switched frequencies, 
which would prevent contact with the next controller. 
When this happened, the pilot would generally re- 
turn to the previous ATC frequency to report the in- 
ability to contact the next controller. The researcher 
in the cockpit, in this case, used a separate, non- ATC 
line to advise the controller to return to the previ- 
ous frequency. In other cases, the researcher in the 
cockpit cleared the problem and used the non-ATC 
line to advise the controller that the pilot had at- 
tempted a call. The controller would then call the 
pilot with a message such as “Last aircraft calling, 
say again.” The pilots participating in the study re- 
ported that this problem actually increased the re- 
alism of the simulation, since similar difficulties and 
corrective actions occur in the real world. Finally, 
the airplane math model provided very little pitch 
stability and required the pilot to spend more time 
on basic attitude control than would be necessary in 
an actual airplane. The low pitch stability was con- 
sidered desirable (by the researcher) from the aspect 
of using increased pilot work load to increase the sen- 
sitivity of the study to differences in work load with 
and without data link. 

Experiment Matrix and Test Procedure 

Prior to any data runs, each pilot was given a min- 
imum of 3 hr of familiarization with the simulator, 
the Denver ATC environment, and the data-link lev- 
els. The practice sessions included complete arrival 
and departure runs, with the data link, over routes 
that were different from the ones used in the data 
runs. The experimental matrix is shown in table 1. 
Each pilot flew a total of 10 data runs. Two runs in- 
troduced abnormal conditions involving aircraft sys- 
tem malfunctions. The remaining eight runs were 


equally divided between arrivals and departures. The 
first run for any pilot was with voice only, to provide 
additional familiarity with the environment, and the 
data-link levels were presented in order of increasing 
levels of capability. Four pilots participated in the 
study, two of which were NASA research test pilots. 
All pilots were qualified for the operation being sim- 
ulated and held at least a commercial certificate with 
multiengine and instrument ratings. 

Data 

The data collected during the study included the 
number of data-link messages sent by ATC and by 
the pilot, the time taken by the pilot to acknowledge 
data-link messages, and the time and duration of 
controller and pilot voice transmissions. Only ATC 
transmissions to the subject airplane were counted; 
a separate controller headset was used for transmis- 
sions to other aircraft. Data for controller voice 
transmissions were derived from a voice-activated 
discrete signal. The data were filtered so that ATC 
transmissions to the subject airplane that were less 
than 1 sec apart were counted as one message. The 
voice data for pilot transmissions were derived from 
the pilot’s push-to-talk switch, which was not sub- 
ject to this problem. Information on the number of 
times the cockpit printer was used, the time used by 
the pilot to compose down-link messages, and the use 
of the data-link weather page were also included in 
the data set. Pilots were encouraged to make brief 
comments during the data runs, when appropriate, 
and a list of questions were asked of the pilots af- 
ter the data runs. Finally, researcher observations of 
pilot/data-link interaction were included in the anal- 
ysis. The data set collected made possible an anal- 
ysis of the effect of the different levels of data link 
on voice communications and on pilot response time 
to ATC. The observations and pilot comments made 
possible an analysis of the impact of the data link on 
the piloting task. 

Results and Discussion 

The data were examined to determine how the 
data link affected the communication activity be- 
tween the pilot and controller. The time required for 
pilot response to ATC data-link and voice messages 
and the number of data-link and voice messages for 
each data-link level were determined. The interac- 
tion of the use of data link with other cockpit tasks 
and pilot acceptance of the data link were examined. 

Response Time to ATC 

The pilot response time to messages is defined as 
the interval between receipt of a message by the pilot 
and the acknowledgment of that message by the pilot. 
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The time interval between pilot receipt of a message 
and the performance of any action required by that 
message, such as initiating a turn, is not considered 
in the response time. For voice transmissions, the 
response times were determined by manually timing 
the interval between the end of an ATC transmis- 
sion and the beginning of the pilot response. This 
determination was made using voice recordings for a 
small sample of the data runs after all runs had been 
completed. For data-link transmissions, the response 
times were recorded digitally during all data runs and 
are the intervals between a message being received in 
the cockpit and the pilot pressing either the “YES” 
or “NO” button. This time interval includes the time 
required for the messages to be written on the CRT, 
which may vary from 0.5 sec to 6 sec. A detailed 
discussion of data-link hardware time delays is pre- 
sented in the appendix. No effort was made to ad- 
just the response times for this factor, since the pi- 
lots generally did not begin to read and comprehend 
the messages until the messages had been completely 
written; voice messages could be comprehended while 
the controller was still speaking. 

A breakdown of data-link response times, as a 
function of scenario type and data-link level, is pre- 
sented in table 2. The mean and standard deviation 
of voice response times, for a sample of all runs, were 
0.9 sec and 0.7 sec, respectively. The response times 
were significantly greater with data link; response 
time began with a mean of 5.8 sec for level 2 and in- 
creased to a mean of 11.6 sec for level 3. In data-link 
level 2, the message writing time was only 0.5 sec. 
The variation in data-link response times was also 
large. Of the total of 297 data-link messages sent 
to the airplane during the study, 20 of the responses 
took longer than 20 sec, 9 exceeded 30 sec, 4 exceeded 
40 sec, and 2 took longer than 1 min. The longest 
response time was 69 sec. 

Several factors appear to be involved in the re- 
sponse delays. One is that the pilots generally did 
not read a message immediately if another task was 
in progress when the message was received. An ex- 
ample would be a message received just as the pilot 
was leveling at a new altitude and resetting power 
and pitch trim. In this type of situation, the pilots 
tended to complete the maneuver prior to reading the 
data-link message. Another factor is that the pilots 
would frequently perform the action required by a 
message prior to acknowledging the message. An ex- 
ample of this would be receiving a clearance to turn 
to a new heading. The pilots frequently set the HSI 
heading bug to the new heading and began the turn 
prior to acknowledging the message. 

Another factor in the response delays was the oc- 
casional reluctance of a pilot to acknowledge a clear- 


ance until the pilot had considered the implications 
of the clearance and had decided that the clearance 
was acceptable. This situation frequently occurred 
after receiving the initial IFR departure clearance. 
In present-day voice operations, pilots acknowledge 
receipt of that clearance, then consider the rout- 
ing, and call the controller back if there is an ob- 
jection or question. The protocol for replying to 
messages may have contributed to this factor. The 
“YES” button performed the dual functions of ac- 
knowledging and accepting clearances (roger and will 
comply, WILCO). The “NO” button performed the 
dual functions of acknowledging and refusing clear- 
ances (roger and unable). It is possible that had a 
“STANDBY” feature been provided, the pilots would 
have more quickly acknowledged receipt of messages 
during busy situations. During the entire set of data 
runs, the “NO” button was only used in four situ- 
ations, twice to refuse an altitude assignment and 
twice to refuse a vector given shortly after takeoff. 

Yet another factor that contributed to response 
delays in a few cases was the requirement for the pilot 
to switch from the weather page to the ATC page, in 
data-link level 4, if the weather page was active when 
an ATC message was received. The visual and aural 
annunciations of message receipt were not factors in 
the delays. The annunciations provided adequate 
notification, and none of the pilots reported being 
unaware that a message had been received. 

A common trend in most of the delays was that 
the pilot processed the data-link information when 
time permitted, rather than as the data were being 
received, as must be done in voice communications. 
When using the data link, pilots had less interaction 
with a person and more interaction with a machine. 
The urgency of responding to a person on the ground 
appeared to diminish. The pilots reported liking 
the fact that the message stayed on the CRT for 
later reference. The pilots also cited the priorities 
taught in flight training — to aviate, navigate, and 
communicate, in that order. The data link enabled 
the pilots to push the communication task farther 
back in time during busy periods. 

Communication Errors 

One objective of the effort was to determine 
how the rate of communication errors, such as mis- 
understood altitude assignments, would be affected 
by data link. A few errors occurred during the study, 
but they were too few in number for a statistical 
analysis. For voice transmissions, there were several 
cases of pilots requesting that heading or frequency 
assignments be repeated. Examples of errors include 
the case of a pilot who was given an initial clearance 
that included V19; the pilot searched the chart for a 
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V191. In another initial clearance, a pilot was given 
a transponder code of 5263, but he copied it as 4263. 
Finally, while being vectored during an arrival run, a 
pilot was told to expect an ILS approach to runway 
35R; the pilot understood and read back runway 26L. 

During the data-link runs, a pilot misunderstood 
a message to change radio frequency and acknowl- 
edged an old heading assignment that was being 
scrolled up on the CRT to make room for the new 
message. The pilot then reset the heading bug to 
the erroneous value. The opportunity for the pilot 
to read and execute a previous message when receiv- 
ing a new message could be reduced by displaying 
only the most recent clearance or by modifying the 
interface to instantaneously write the new message 
display. In another incident, the controller acciden- 
tally sent a data-link message requesting a descent 
to 1000 ft, but 10000 ft was the intended message. 
The pilot accepted this clearance before realizing the 
error. Terrain elevation in the simulated area was 
above 5000 ft. Although the pilots generally did not 
acknowledge messages until after reading them, there 
were many cases of the pilot pressing the “YES” but- 
ton prior to a message being completely written on 
the CRT. In yet another situation, a 500-ft altitude 
deviation occurred when the airplane passed through 
an assigned altitude, in a descent, while the pilot was 
occupied with getting ATIS information on the data 
link. 

Pilot comments suggest that misunderstood mes- 
sages would occur less often with data link than with 
voice only. All pilots reported frequent use of the 
data link, especially the dedicated heading and al- 
titude display, as a reminder of the last clearance 
received. One pilot indicated that the data link took 
the place of a separate altitude-reminder device. 

Communication Activity 

For each run, the total number of voice and 
data-link messages and the duration of the voice 
messages were recorded. Table 3 shows the average 
number of ATC voice messages to the airplane per 
run and the average duration of those transmissions 
for each data-link level. The data are broken out 
by scenario type: arrival, departure, communication 
failure, engine failure, and all nonemergency runs. 
Except for the engine-failure scenario, all data runs 
were of approximately the same length of time and 
flight distance, so the number of transmissions per 
run can be directly compared. 

The number of voice transmissions per run steadily 
decreased as the data-link capability increased. In 
the baseline voice runs, ATC made about 21 trans- 
missions to the airplane per run. This fell 31 percent, 
to about 14.5 calls per run, with the up link of only 


heading and altitude to the airplane. A large reduc- 
tion in voice activity occurred when the ability to 
send text messages was used. The number of ATC 
voice transmissions to the airplane fell to about seven 
per run in data-link level 3, for a reduction of 67 per- 
cent from the baseline level. A very small additional 
reduction in the number of calls occurred when the 
pilot was given the down-link capability of level 4, 
to about six calls per run. The average duration of 
the ATC transmissions to the airplane remained al- 
most constant between data-link levels; it varied from 
about 4.5 sec per transmission with levels 1 and 2 to 
about 3.5 sec per call with levels 3 and 4. 

The data-link activity from ATC to the subject 
airplane is shown in table 4. The average number 
of data-link messages per run was at 6.4 for data- 
link level 2 and increased to about 10 for the highest 
data-link level. In level 4, any weather data up linked 
to the airplane, that was requested by the pilot us- 
ing the weather page, was not considered to be an 
ATC message and is not included in the count. The 
number of data-link transmissions per run did not 
increase with increased data-link levels as rapidly as 
the number of voice transmissions decreased. This 
trend is indicated by the data in table 5, which lists 
the average number of ATC transmissions, both data 
link and voice, per run. The total number of mes- 
sages began at 21.3 per run for level 1 and gradu- 
ally decreased to 15.6 for level 4. Therefore, there 
were 26 percent fewer ATC messages to the airplane 
than with the voice baseline at the highest data-link 
level. Possible reasons for the reduction include fewer 
missed calls, fewer requests to repeat information, 
and fewer multiple-transmission “conversations” be- 
tween the pilot and ATC because of the concise na- 
ture of the data-link messages. 

The voice activity by the pilots is summarized in 
table 6, which shows the number of pilot transmis- 
sions per run and the average length of those mes- 
sages. The trend is similar to the ATC voice activ- 
ity; there is steadily decreasing voice activity with 
increases in the data-link capability. The pilot voice 
activity was reduced 67 percent from the baseline 
with data-link level 4. 

Mixing of Voice and Data-Link Messages 

The voice channel of communication was retained 
and used in the data-link runs. Each hand-off to a 
new controller involved a voice communication with 
the receiving controller, and any unusual requests or 
negotiations were handled by voice. A general rule 
in the study was that any given message would be 
sent either via voice or data link, but not by both. 
Exceptions occurred in data-link level 2, where mes- 
sages such as the instrument-approach clearance had 
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to be sent via voice and where the clearance con- 
tained a heading and/or altitude to fly. In that case, 
the heading and/or altitude portion of the clearance 
was also transmitted via the data link. Exceptions 
also occurred, in all data-link levels, for situations in 
which the pilot negotiated a new heading or altitude 
verbally with the controller. Once the negotiation 
was begun with voice, it was completed with voice, 
but the new clearance was then sent up via the data 
link. 

The pilots, with a few exceptions, reported that 
the mix of voice and data-link communications 
seemed completely natural. Exceptions to the posi- 
tive comments on the mix of voice and data link in- 
cluded situations that involved critical weather and 
communications with the local controller (control 
tower). With respect to weather, one pilot com- 
mented that any requests for deviations, for example, 
a heading to avoid thunderstorms, should be han- 
dled by voice to minimize pilot work load and to let 
other pilots in the vicinity know what is happening. 
The pilots generally reported that they liked the re- 
duced activity on the radio, but that they would miss 
the “party-line” effect in critical weather situations. 
With respect to communication with the local con- 
troller, all four pilots strongly recommended the use 
of voice for receiving the clearances to taxi onto the 
runway and to takeoff. The data-link capability in 
level 4 enabled the pilot to request and receive take- 
off clearance without talking to the local controller, 
and a few takeoffs were made that way. The pilots 
believed that the takeoff clearance was so critical, 
and that establishing radio contact with the tower 
was important enough, that the data link should not 
be used as the sole channel for takeoff clearance. Use 
of the data link to confirm the clearance (ATC send- 
ing the clearance on both voice and data link) was 
reported to be acceptable, as was the use of only 
data link for landing clearance. For landing, how- 
ever, the pilots were occasionally given clearance via 
the data link when they were close to the airport 
and at low altitude. The pilots reported that a late 
landing clearance should be given via voice, since the 
visual channel is already heavily loaded from tracking 
the ILS display. With respect to receiving a message 
on both the voice and data-link channels, one com- 
ment indicated that it seemed strange to receive the 
data-link message after the voice message. With a 
time delay between the voice and data-link messages 
of only 5 to 10 sec, a pilot may initially believe that 
the data-link message represents a change from the 
voice message that was just given. 

The results suggest that the data-link and voice 
channels of communication with ATC can be inte- 
grated, in single-pilot operations, in a manner that 


seems natural to the pilot. The data link can as- 
sist the pilot with most routine, highly structured 
messages, and the voice channel is available for ne- 
gotiations and less-structured messages. 

Data-Link Interface Effects 

The pilot interface with the data-link capability 
influenced the use of that capability and the pilot 
comments. The interface was examined with respect 
to message alerting, screen display, speed of opera- 
tion, and keyboard layout. 

The audio tone and annunciator light were ade- 
quate for alerting the pilot that a new message had 
been received. There were no occurrences of a pi- 
lot not being aware that a message had been re- 
ceived. One pilot reported, however, that the audio 
alert tone could possibly be confused with the audio 
from a marker beacon during an ILS approach. Other 
comments were received requesting that the data-link 
interface permit the pilot to silence the audio alert 
prior to reading or acknowledging the message. 

The CRT display format generally provided the 
up-linked messages in an easy-to-read manner. The 
pilots commented that the print was easy to read, 
that the use of inverse video made the new, unac- 
knowledged messages obvious and easy to pick out, 
and that the messages and abbreviations were easy to 
interpret. A few problems were found, however, with 
the retention and scrolling of old textual messages on 
the display. Pilot comments indicated that, although 
the indentation used to group messages helped de- 
clutter the display, the old messages were jumbled 
together. One pilot suggested that a blank line be 
used between messages. Another pilot reported that 
the display was excessively cluttered with old mes- 
sages and that he wanted an interface feature to erase 
all the old messages. As noted in the section “Com- 
munication Errors,” one error occurred when a pilot 
read an old message and believed it to be the current 
clearance. Other comments suggested that only the 
most recent message remain on the CRT and that 
all old messages be sent either to a buffer or to the 
cockpit printer. 

As noted previously, there were time delays be- 
tween the annunciation of an incoming textual data- 
link message and the actual display of that message. 
Most pilots reported that during the delay between 
message alert and completion of writing, they tem- 
porarily ignored the data link and then included it 
in their instrument scan until the presence of in- 
verse video indicated that the message had been writ- 
ten. On a few occasions, however, a pilot stared at 
the data-link display while old messages were being 
scrolled up and the new message was being written. 
The resulting interruption in the primary instrument 
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scan resulted in deviations from assigned altitudes 
and paths and, in one case, occurred while tracking 
an ILS. These results suggest that a data-link inter- 
face should have very short display-write times and 
should not alert the pilot to a new message until the 
message is actually being displayed. The time re- 
quired to send the contents of the data-link display 
to the cockpit printer, 31 sec, affected the utility of 
the printer. During that write time, the data-link 
system could not be used for any other function. The 
pilots indicated that this was not completely satisfac- 
tory and that the printer would have been used more 
often if the delay had not been present. 

The keyboard interface with the data link worked 
well and generally received positive comments. Since 
only very simple down-link messages were possible, 
keyboard use was kept to a minimum. The keyboard 
buttons applicable to each data-link level were in- 
ternally illuminated for runs with that level, which 
effectively decluttered the keyboard for the runs with 
the lower data-link capability levels. Pilot comments 
indicated that the keyboard arrangement was easy to 
use, but one pilot suggested an alternate layout with 
ATC message buttons in one group and a separate 
group of weather-product buttons. The proposed 
weather information group included a dedicated but- 
ton for each weather product available, such as the 
ATIS information; this group could eliminate the 
need for a separate weather data page on the CRT. 
Other pilot comments suggested that the ”YES” ac- 
knowledgment button could be more quickly and 
easily used if it were placed on the pilot’s control 
yoke. Other comments questioned the protocol used 
to send a down-link message, where one button was 
pressed to select the message and display it in the 
scratch-pad area, and then the “SEND” button was 
pressed. The comments suggested that the message 
should be selected and sent with only one push of a 
button. 

Overall, the pilot interface with the data-link ca- 
pability was sufficiently simple and easy to use for 
general-aviation, single-pilot operations. An opera- 
tional unit, however, would require improvement in 
the speed of operation and a reduction in display 
clutter, possibly by displaying only the most recent 
message. 

Data-Link Use/Cockpit Task Interaction 

The pilot comments indicated that, in general, 
the use of the data-link device did not interfere with 
other cockpit tasks. Exceptions occurred when the 
pilot was heavily loaded with other tasks, especially 
in the visual channel, when the data-link message 
was received. Examples include receiving a data- 
link message while in the process of intercepting a 


localizer, while close to the ground during an ILS 
approach, while taxiing onto a runway for takeoff, or 
while still at low altitude shortly after takeoff. In 
these cases, pilot comments indicated that the data- 
link messages interfered with the primary task. In a 
few such cases, flight-path deviations resulted. 

Although the data link rarely interfered with the 
performance of cockpit tasks, the cockpit tasks often 
interfered with the use of the data link. As described 
previously, messages received while the pilot was 
busy with such tasks as capturing an altitude were 
often ignored until the task was completed. 

Utility of Data-Link Levels 

The pilots were asked for their assessments of the 
relative utility of the various data-link levels. The 
answers generally indicated that the most basic data- 
link capability, level 2, created a large improvement 
in ATC communications over the voice baseline. Pi- 
lots reported the improvements by saying that they 
were “much more relaxed” and that the data link 
“made life easier” during the flights. The data-link 
benefits increased as the data-link level increased be- 
yond level 2, but at a lower rate. One comment indi- 
cated that simply having the heading, altitude, and 
weather information on a data link would make for a 
very useful capability level. 

At the highest level of data-link capability, level 4, 
the pilots indicated that the complexity and capabil- 
ity had become more than was necessary. One pilot 
stated that he did very little with the down-link ca- 
pability and that most of the benefits existed only 
with up link. Another comment was that level 4 was 
excessive for a single-pilot operation. Yet another 
opinion was that level 3 was best and that level 4 was 
too complex. No comments were received to indicate 
that level 3 was too complex. The only difference 
between the two levels was the ability to down link 
messages in level 4. The use of terminal-area opera- 
tions for this study may have affected this result, as 
some pilot comments indicated that more use would 
be made of the down-link capability in the lower work 
load, en route phase of flight, especially for acquir- 
ing weather data. The overall results suggest that 
as the up-link capability increased, the benefits to 
the pilot increased by reducing demands on the pi- 
lot’s short-term memory and by allowing the pilot 
to delay responding to ATC during high-work-load 
events. The down-link capability, however, increased 
the pilot’s work load. 

Concluding Remarks 

The use of digital data link for communications 
between pilots and air traffic control (ATC) provided 
benefits to pilots in simulated, general-aviation, 
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single-pilot operations. The data link reduced de- 
mands on the short-term memory of the pilots, re- 
duced the number of communication transmissions, 
and permitted the pilots to more easily allocate time 
to critical cockpit tasks while receiving ATC mes- 
sages. The four pilots who participated in the study 
unanimously indicated a preference for data-link 
communications over voice-only communications. In 
particular, the use of the data link to receive ini- 
tial instrument-flight-rule (IFR) route clearances and 
automatic terminal information service (ATIS) mes- 
sages, and as a reminder of the most recently assigned 
heading and altitude, was preferred by the pilots. A 
mix of voice and data-link communications was used 
in the data-link runs, and the protocol used to mix 
the communications was reported by the pilots as 
acceptable and natural to use. 

The pilots perceived benefits with even the sim- 
plest data-link capability level and preferred the 
higher data-link capabilities, which accommodated 
the up link of textual data. The pilots had little 
use, however, for the capability to down link mes- 
sages to ATC; they preferred to use voice for negoti- 
ating clearances or making requests. For this reason, 
and because of the fact that the scenarios did not 
require in-flight gathering of en route weather infor- 
mation, the down-link capability was primarily used 
for requesting initial IFR route clearances and ATIS 
information. 

The use of data link caused concern or problems 
for the pilots in certain situations. Communication 


with the local controller during taxi onto a runway 
and during takeoff was judged, by all four pilots, 
to be too time critical to be received by only data 
link. The strong preference was for clearance to 
be given by voice, but data-link was acceptable as 
a backup. Reception of messages by data link was 
also not considered acceptable when the pilot was 
heavily loaded visually with a control task; such as 
intercepting the instrument landing system (ILS), 
tracking the ILS at low altitude, landing, taking off, 
or taxiing. 

Data-link communications, as simulated in this 
effort, have the potential to create problems for the 
ATC system. The time required to transmit a mes- 
sage was greater than with voice. Additional delays 
in the action taken on tactical, messages by the pi- 
lot occurred when the pilot delayed reading messages 
during high-work-load tasks. Another delay, in the 
acknowledgment of ATC messages, occurred when 
the pilot accomplished the task required by a mes- 
sage before giving an acknowledgment. When using 
the data link, pilots had less interaction with a per- 
son and more interaction with a machine, and the ur- 
gency of responding to a controller’s message tended 
to disappear. No attempt was made in this research 
to investigate the interface between controllers and a 
data-link capability; research in this area is needed 
to ensure the development of an effective system. 

NASA Langley Research Center 
Hampton, VA 23665-5225 
September 15, 1988 
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Appendix 

Details of Data-Link Displays, Keyboard, 
and Messages 

Patricia B. Naftel 

Research Triangle Institute 

Research Triangle Park, North Carolina 

Data-Link Screen and Keyboard Format 

Data-link messages received in the cockpit were 
displayed on a black and white, rectangular cathode 
ray tube (CRT) mounted in the center of the cock- 
pit instrument panel (fig. 1). Responses to up-link 
messages, as well as to pilot-initiated down-link mes- 
sages, were achieved via a keyboard below the CRT. 
The CRT and keyboard are shown in figure 3. De- 
tails of the data-link display vary as a function of the 
data-link capability level. Some displays contain only 
a minimal amount of information for the pilot, while 
others provide controller commands in full detail. 

The large central section of the CRT (see fig. 9) 
displayed data-link messages in textual form and 
is referred to herein as the text area. This area 
could accommodate up to eight lines of text, with 
each line containing a maximum of 30 characters. 
Multiple-line messages were indented slightly after 
the first line to enhance message recognition. New 
messages were displayed in inverse video until the 
pilot acknowledged them. 

At the bottom of the text area were two boxes 
dedicated to showing the most recent heading and 
altitude assignments. These areas are referred to 
herein as the dedicated windows. The heading was 
displayed in degrees from magnetic north, and the 
altitude was displayed in feet. If an air traffic control 
(ATC) message instructed the pilot to turn left or 
right to a heading, then a letter L or R, respectively, 
also appeared in the heading window. An up or 
down arrow, as appropriate, appeared in the altitude 
window to command the pilot to climb and maintain, 
or descend and maintain, an assigned altitude. 

Flanking the text area were two vertical rectan- 
gular regions which contained display status infor- 
mation for the pilot. The left area contained either 
“ATC” or “WX” to indicate that the current display 
“page” contained controller messages or weather in- 
formation, respectively. The right area was blank 
when the current ATC or weather page was dis- 
played, and was filled with a column of B’s when an 
information “buffer” was being viewed. These buffers 
contained previous messages which were scrolled off 
the primary ATC or weather page as those pages 
were filled with information. 


Data-link level 4 featured a single-line work area, 
or scratch pad, between the text area and the dedi- 
cated windows. This scratch pad provided the pilot 
with a space in which to generate down-link mes- 
sages. These messages were kept simple in structure 
and consisted of requests for clearances, taxi, take- 
off, heading changes, altitude changes, and weather 
information. The scratch pad allowed the pilot to 
preview and make corrections to the message before 
it was sent or to cancel the message altogether. 

Data-Link Levels 

The complexity of the data-link display varied 
as a function of the data-link capability level. An 
example of the display, for data-link level 4, is shown 
in figure 9. Lower data-link levels show subsets of the 
display components that are used in level 4. There 
were four distinct data-link levels. Data-link level 1 
was a baseline, voice-only mode. No information 
appeared in any of the screen viewing areas, and the 
keyboard was inoperative. 

In data-link level 2, heading and altitude informa- 
tion only was extracted from the ATC messages and 
was depicted in the dedicated windows at the bot- 
tom of the CRT. No other data-link information or 
capabilities (i.e., weather-product data, printer func- 
tion, pilot down link) were available to the pilot in 
this level. Only the “YES” and “NO” buttons on the 
cockpit keyboard were operative. 

In data-link level 3, the same heading and alti- 
tude information described in level 2, with several 
enhancements, was shown. Along with the heading 
and altitude information, ATC messages appeared in 
the text area of the CRT. The text area also provided 
the pilot with buffers of previous messages. As the 
text area of the display became filled, prior messages 
were automatically scrolled into the buffers to make 
room for new messages. The buffers were accessed 
via the “LAST MSG” button on the data-link key- 
board. Each depression of this button caused a prior 
time-history buffer of information to be displayed on 
the CRT. Buffer data were flagged by a column of 
B’s in the panel flanking the right side of the text 
area. Figure 10 provides an example of a buffer 
display. After viewing buffer information, the pilot 
could return to the current ATC message display via 
the “ATC PAGE” button. 

Data-link level 3 also provided the pilot with 
the ability to obtain a hard-copy printout of the 
CRT display. This was accomplished by pressing the 
“PRINT” button on the data-link keyboard. This 
button activated a small printer installed beneath 
the copilot’s side of the instrument panel. Because 
the printer had no data buffer, the other functions 


13 


of the data link were temporarily suspended during 
printing. 

Data-link level 4 included all the features of level 3 
plus the ability to down-link requests to the ground, 
including requests for weather information. The 
CRT display format was modified by the addition 
of a one-line scratch pad that separated the dedi- 
cated windows from the text area. This scratch pad 
was used by the pilot to compose down-link messages 
to the controller. Message composition was accom- 
plished via specific buttons on the cockpit keyboard 
and included requests for the initial route clearance, 
taxi, takeoff, and for heading and altitude changes. 

Data-Link Keyboard 

The data-link keyboard consisted of a four- 
column, eight-row rectangular matrix of buttons 
which, when pressed, triggered various functions. 
The buttons had a white background with black let- 
tering. The keyboard was organized so that the but- 
tons to be used most often, and that were used with 
each data-link level, were closest to the CRT dis- 
play. These were the “YES” and “NO” buttons used 
for acknowledgment of ATC messages. Pressing the 
YES button performed the dual functions of ac- 
knowledging and accepting a clearance. Pressing the 
NO button acknowledged the message and indi- 
cated to the controller that the pilot could not com- 
ply. In that case the pilot or controller would use the 
voice-communications channel to negotiate a clear- 
ance. The YES and “NO” buttons were placed at 
opposite ends of the top row of buttons to reduce the 
possibility of a pilot inadvertently pressing the wrong 
one. Immediately between and below the “YES” and 
“NO” buttons were those buttons used to control the 
data-link display. These buttons selected the cur- 
rent ATC page, weather page, or last-message buffer 
pages, cleared the text area of the display, and acti- 
vated the printer. Except for the weather-page select, 
all these buttons were active in data-link level 3. The 
down-link capability of data-link level 4 required but- 
tons for selecting the desired message, a button for 
selecting the weather page, and a “SEND” button. 

In an attempt to simplify operation of the data link, 
a full alphanumeric keyboard was not implemented, 
and a menu and a fill-in-the-blank method of compos- 
ing down-link messages were used. The buttons used 
to select messages that required no additional input 
prior to being sent were arranged to the left of the 
SEND button and above the numeric keyboard. 
The buttons used to select messages that did require 
additional input, such as altitude requests, were ar- 
ranged below the “SEND” button and to the right of 
the numeric keyboard. Details of message composi- 
tion and down link are given in the sections “Sending 


Messages From the Cockpit” and “Weather-Product 
Page.” 

The buttons that were active for any particu- 
lar data-link level were illuminated with an inter- 
nal light during that run. In level 1 (voice only), 
none of the buttons were illuminated. In level 2, 
only the “YES” and “NO” acknowledgment buttons 
were illuminated. In data-link level 3, the “YES ” 
“NO,” “ATC PAGE,” “PRINT,” “LAST MSG,” and 
“CLEAR” buttons were illuminated. In data-link 
level 4, all the labeled buttons were illuminated. Sev- 
eral unlabeled buttons, provided as spares for future 
development, were never used or illuminated. 

Cockpit Message Reception and 
Acknowledgment 

Reception of an ATC message in the cockpit 
sounded an audio alarm and turned on an annun- 
ciator light above the attitude indicator on the cock- 
pit instrument panel. The audio alert sounded when 
a message was received, then went silent. If the 
message were not acknowledged within 10 sec, the 
audio tone would sound again. This sequence con- 
tinued until the message was acknowledged. The 
annunciator light remained illuminated until the pi- 
lot acknowledged the new message. Newly received 
messages were displayed in inverse video to visually 
highlight those messages on the CRT. If the new 
message contained new heading or altitude assign- 
ments, this information was also extracted and ap- 
peared in inverse video in the dedicated windows. 
The pilot acknowledged the message by pressing ei- 
ther the YES ’ or “NO” button on the keyboard, de- 
pending upon whether the pilot accepted or rejected 
the ATC command. Depression of the “YES” but- 
ton caused the new message information, including 
any new heading or altitude assignments associated 
with the message, to be displayed in normal video. 

A NO erased the new message from the screen and 
caused backscrolling of the ATC buffers, as neces- 
sary, to restore the ATC page display to its original 
contents prior to message reception. A “NO” also 
erased any new heading and/or altitude information 
in the dedicated windows and restored the previous 
data depicted in those windows. 

In data-link levels 3 and 4, it was possible for an 
ATC message to be received while the pilot was view- 
ing another page, such as a buffer or a weather page. 

In this case, both the audio and visual annunciations 
were given, and the pilot could see new information 
in the dedicated windows, which were always visible. 

To view the textual component of the new message, 
it was necessary for the pilot to manually select the 
ATC page by pressing the “ATC PAGE” button. It 
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was possible to acknowledge the new message, how- 
ever, without selecting the ATC page. 

As the text area filled with new messages, auto- 
matic scrolling occurred which placed former mes- 
sages into buffers which could later be recalled for 
review by the pilot. Scrolling was based on message 
length; that is, if the current display consisted of two 
messages, the first containing four lines and the sec- 
ond containing three lines, a new two- line message 
(which would exceed the maximum eight-line limit) 
would cause all four lines of the first message to scroll 
into the buffer. Thus, the new display that was pro- 
duced consisted of the previous three- line message 
plus the new two-line message. 

Sending Messages From the Cockpit 

Level-4 data-link operations provided the pilot 
with the capability of composing and sending down- 
link messages to the controller. Messages to be down 
linked were selected from the menu provided on the 
keyboard and appeared in the one-line scratch-pad 
area for additional composition or review by the pi- 
lot. Messages to be down linked appeared in inverse 
video while being composed. After composing a mes- 
sage, the pilot could transmit it to ATC by pressing 
the “SEND” button. Depression of this button si- 
multaneously changed the scratch-pad display of the 
down-link message to normal video. 

Three of the available down-link messages re- 
quired no additional composing after being selected. 
These were requests for the initial route clearance 
(“REQ CLEARANCE” button), requests for ground 
taxi clearance (“REQ TAXI” button), and requests 
for takeoff clearance (“REQ TAKEOFF” button). 
Pressing the appropriate button caused the corre- 
sponding message to appear in the scratch pad, ready 
to be sent. 

Heading and altitude requests further required 
the numeric input of the desired heading or altitude. 
Pressing the “REQ HDG” button or the “REQ ALT” 
button placed the appropriate message in the scratch 
pad with either three or five blank spaces, respec- 
tively, which were filled in by the pilot. The numeric 
keypad was used to type in the desired heading, in 
degrees, or the desired altitude, in feet. The entire 
scratch-pad area remained in inverse video while the 
message was being composed. 

If the pilot made a mistake while entering in- 
formation, or decided not to send the message, the 
“BACK SPC” button could be used to erase incor- 
rect information. One numeric digit was erased each 
time “BACK SPC 51 was pressed, and data items were 
erased in the reverse order in which they had been 
entered. Multiple depressions of the “BACK SPC” 


button could be used to erase all the incorrect head- 
ing or altitude numbers. Pressing the “BACK SPC” 
button canceled the message under composition (and 
cleared the scratch pad) once all numeric information 
had been erased, or if the message required no nu- 
meric entry. 

Weather-Product Page 

Data-link level 4 also gave the pilot the capability 
of sending requests, for various weather products, to 
the ground. This was done using the weather page 
of the data-link device. Upon depression of the “WX 
PAGE” button, the screen display changed to depict 
a weather-product menu (fig. 11). The weather-page 
display retained the heading- and altitude-dedicated 
windows and showed “WX” in the left panel flank- 
ing the text area to signal the display of weather 
information. The menu consisted of the following 
numbered choices: 1. departure automatic termi- 
nal information service (ATIS) messages, 2. arrival 
ATIS messages, 3. pilot weather reports (PIREPS), 
4. significant meteorological information advisories 
(SIGMETS), and 5. the local terminal forecast. The 
pilot selected the desired weather product by pressing 
the corresponding number on the numeric keypad; 
the weather-product choice was displayed in inverse 
video in the scratch-pad area. If the pilot was sat- 
isfied with the choice, pressing the “SEND” button 
would down link the request. Depression of “SEND” 
also caused the request in the scratch pad to appear 
in normal video, to signal to the pilot that down link 
of the request had occurred. After a delay of about 
6 sec, the requested weather information would ap- 
pear in the text area. A down-link request could be 
canceled, prior to sending it, by pressing the “BACK 
SPC” button. Another selection could then be made. 
The weather information that was up linked for each 
product request is shown in table 7. 

When viewing the weather-product menu, the 
pilot could also view previously up-linked weather 
information by pressing the “LAST MSG” button. 
This displayed the weather-information buffer page, 
along with a column of B’s in the area to the right 
of the text area. Repeated pressing of the “LAST 
MSG” button would display older buffers of up- 
linked weather data, and the pilot could return to 
the weather-product menu by pressing the “WX 
PAGE” button. The weather- buffer pages and the 
ATC buffer pages were maintained separately, so only 
weather messages were seen on the weather- buffer 
pages. 

There were three versions of the arrival ATIS mes- 
sage. The one that was relevant to a particular run 
was selected at run setup time and remained current 
for the duration of the run, unless it was changed 
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via physical input at the controller workstation. One 
data-link scenario involved an emergency situation 
in which the arrival ATIS was up linked, by the con- 
troller, to accommodate an emergency return to the 
airport. Otherwise, the functioning of the weather- 
product data-link service was strictly automatic and 
required no response from the controller. The process 
was intended to simulate the pilot querying a central 
weather facility and automatically receiving the re- 
quested information. Also, since no alpha keyboard 
was provided, it was not possible with this partic- 
ular data-link interface to specify an airport when 
requesting a terminal forecast. For the purposes of 
this study, it was sufficient to simply provide the ter- 
minal forecast for Denver. 

Since the controller was not involved with the up 
link of weather products that were requested on the 
weather page, the up-link information appeared in 
normal video and no “YES” or “NO” acknowledg- 
ment of that up-link weather information was re- 
quired. No audio or visual alarms were given upon 
receipt of the requested weather information. On the 
other hand, the controller could send an up-link mes- 
sage containing any of the weather-product items. 
These messages then became part of the controller 
message display in the cockpit; they were accompa- 
nied by both the light and sound annunciators and 
were displayed in inverse video until acknowledged 
by the pilot. 

Use of Cockpit Printer 

A small thermal printer (4.5 in. wide by 2.7 in. 
high by 5.7 in. deep) was mounted beneath the 
cockpit panel on the copilot’s side of the cockpit for 
use in the level 3 and level 4 data-link scenarios. 
The paper width was 3.125 in. The printer function 
was activated via the keyboard “PRINT” button and 
provided a hard copy of the contents of the current 
page. This hard copy included: a header of either 
ATC or WX designation to indicate whether ATC 
data or weather data were being viewed; a rightmost 
column of B’s when a buffer was being viewed; the 
dedicated-window heading and altitude assignments; 
and the contents of the text area. When the screen 
display had been printed, the pilot could read it by 
tearing off the hard copy from the printer. 

Two drawbacks of the utilization of the printer 
were the slow speed with which the printer per- 
formed its task and the lack of data buffering in the 
printer itself. The printer took about 31 sec to pro- 
vide its output, and the lack of buffering suspended 
other data-link functions until the printer output was 
completed. 


Controller Operation of Data Link 

Data-link messages were sent to the cockpit, via 
an RS-232 interface and a video cable, from an 
IBM AT computer located in the Langley Mission- 
Oriented Terminal-Area Simulation (MOTAS) Fa- 
cility. The RS-232 interface connected the cockpit 
data-link keyboard to the IBM AT computer, where 
the pilot inputs were actually processed. The cock- 
pit data-link display was an image of the IBM AT 
graphic display, which was also being shown in the 
MOTAS facility at the controller’s workstation. By 
viewing the display, the controller could see when 
an up- link message had been acknowledged (inverse 
video changing to normal video) and could see the 
pilot composing and sending down-link messages. 

Controller up-link messages were generated by 
coded input at the IBM AT keyboard with the aid 
of a controller assistant. The code subsequently 
activated the audio and visual message annunciators 
in the cockpit and generated the appropriate cockpit 
screen updates. 

At the beginning of each data-link run, certain ini- 
tialization procedures were performed. Run and pilot 
identification numbers were entered into the IBM AT 
computer to establish predetermined scenario condi- 
tions for the run. These conditions included such 
items as the runway to be used in the scenario, the 
arrival ATIS to be activated for the run, and a coded 
description of the particular scenario itself. The pilot 
was prompted to press a time-synchronization button 
located above and to the right of the data-link key- 
board buttons. This generated a simultaneous sig- 
nal to both the IBM AT (data-link simulation) and 
CYBER 175 (airplane simulation) computers, so that 
the timing of events in the data-link run could later 
be synchronized for data-analysis purposes. 

Data-Link Message Set 

The entire data-link message set was predefined 
for the data-link experiment. Free- form entry of 
messages was not possible. A message to be sent to 
the airplane was entered at the controller workstation 
as a four-letter code followed by additional numeric 
data if needed to specify altitude, heading, radio 
frequency, or runway assignment. To enhance the 
pilot interface with the data link, the development 
of the message set considered the space available 
for message display, standard ATC phraseology, and 
standard abbreviations (ref. 9). The message set is 
shown in table 8. Tables 7 and 8 provide a complete 
list of the messages that could be transmitted to the 
cockpit data-link display from the controller station. 
The messages are shown as they appeared on the 
data-link display. 
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Data-Link System Delays 

The time required by the data-link simulation 
hardware to perform various functions affected the 
data-link interface with the pilot and was a com- 
ponent in the response delays to ATC messages. 
Those times were determined for various combina- 
tions of ATC and weather-message reception, with 
clear and full screens, with scrolling, and with ATC 
and weather pages displayed. The results are shown 
in table 9. 

The time delay from the controller sending a 
message to activation of the annunciation in the 
cockpit was almost zero. The dedicated windows 
that show heading and altitude were also updated 
quickly; there was a delay of about 0.5 sec. The 
time between the transmission of a message by ATC 
and the beginning of the writing of that message, 
however, varied with the amount of text already 
displayed in the text area. With an empty text area, 
the new message began to appear less than 1 sec 
after being sent and took about 0.8 sec per line to be 


written. With a full screen, the old messages were 
first scrolled up to make room for the new message. 
This scrolling process required just over 6 sec, for 
eight lines of text. In general, the data-link interface 
required about 0.8 sec per line for scrolling messages 
and writing messages. 

Switching between the ATC page and the weather 
page required about 7.6 sec in either direction. The 
time was used to write out the weather menu or the 
ATC messages. The only weather product routinely 
requested during the study was ATIS information. 
The time required to finish writing the ATIS infor- 
mation, after the pilot pressed the “SEND” button 
to down link the request, was just under 6 sec. 

When a buffer of previous ATC messages was 
selected with the “LAST MSG” button, about 7 sec 
were required to write out the buffer on the CRT. 
About 7.6 sec were required to return to the ATC 
page. The printer, used to produce a hard copy of 
the contents of the CRT screen, required 31 sec from 
the time that the “PRINT” button was pressed to 
complete printing. 
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Table 1. Data- Run Experimental Matrix 


Run 

Scenario 

Data-link 

level 

ATIS 

message 

Cloud 
ceiling, ft 

Visibility, 

n.mi. 

Pilots 1 and 2 

1 

A4 

1 

Echo 

700 

5 

2 

A3 

2 

Bravo 

450 

2 

3 

A2C 1 

3 

Echo 

700 

5 

4 

A1 

4 

Echo* 2 

700 

5 

5 

A2 

3 

Bravo 

0 

0 

6 

D3 

1 

Delta 

450 

2 

7 

D2 

2 

Delta 

450 

2 

8 

D1 

3 

Delta 

450 

2 

9 

D2E 3 

4 

Delta 

700 

5 

10 

D3 

4 

Delta 

450 

2 

Pilot 3 

1 

D1 

1 

Delta 

450 

2 

2 

D2 

2 

Delta 

450 

2 

3 

D3 

3 

Delta 

700 

5 

4 

D1 

4 

Delta 

450 

2 

5 

D2E 3 

4 

Delta 

450 

2 

6 

A1 

1 

Echo 

700 

5 

7 

A2 

3 

Bravo 

0 

0 

8 

A3C 1 

4 

Echo 

700 

5 

9 

A4 

3 

Bravo 

450 

2 

10 

A3 

3 

Echo* 2 

700 

5 

Pilot 4 

1 

D1 

1 

Delta 

450 

2 

2 

A1 

1 

Echo* 2 

700 

5 

3 

D2 

2 

Delta 

450 

2 

4 

A2 

2 

Bravo 

450 

2 

5 

D3 

3 

Delta 

450 

2 

6 

A3 

3 

Echo 

700 

5 

7 

D2E 3 

3 

Delta 

450 

2 

8 

A4 

4 

Bravo 

0 

0 

9 

D1 

4 

Delta 

450 

2 

10 

AlC 1 

4 

Echo 

700 

5 


Suffix “C” on scenario label indicates that scenario included lost communications. 

2 Echo* indicates that the first ATIS information received by the pilot was Echo and that 
information FOXTROT became current during the run. 

3 Suffix “E” on scenario label indicates that scenario included engine failure. 



Table 2. Mean and Standard Deviation of Pilot Response 
Times to ATC Data-Link Messages 


Scenario 

Mean and standard deviation, 
sec, at — 

Data-link level 

2 

3 

4 


7.2 

9.0 

9.5 

Arrival 

and 

and 

and 


7.0 

7.4 

8.3 


5.8 

11.6 

11.2 

Departure 

and 

and 

and 


4.6 

13.3 

7.6 



8.8 

10.6 

Communication failure 

N/A 

and 

and 



4.1 

5.3 



12.8 

12.8 

Engine failure 

N/A 

and 

and 



5.3 

10.7 


6.5 

10.1 

10.4 

All nonemergency 

and 

and 

and 


5.9 

10.2 

7.9 


20 




Table 3. Average Number of ATC Voice Transmissions Per Run 
to Subject Aircraft and Average Length of Transmissions 

’ Except for engine- failure scenario, all 
runs were approximately the same length 
in time and distance 



Transmissions per run and length 
of transmissions, sec, at — 

Scenario 

Data-link level 

1 

2 

3 

4 

Arrival 

22.3 

and 

4.3 

14.5 

and 

4.4 

7.8 

and 

3.6 

7.0 

and 

3.4 

Departure 

20.3 4 

and 
4.5 

14.8 

and 

5.0 

6.3 
and 

3.4 

5.0 

and 

3.3 

Communication failure 

N/A 

N/A 

1.0 

and 

2.8 

1.0 

and 

1.2 

Engine failure 

N/A 

N/A 

17.0 

and 

3.2 

12.3 

and 

4.6 

All nonemergency 

21.3 

and 

4.4 

J — 

14.6 

and 

4.7 

7.1 

and 

3.5 

5.9 

and 

3.3 



Table 4. Average Number of ATC Data-Link Transmissions 
Per Run to Subject Aircraft 


Except for engine-failure scenario, all 
runs were approximately the same length 
in time and distance 


Scenario 

Transmissions per run and length 
of transmissions, sec, at — 

Data-link level 

1 

2 

3 

4 

Arrival 

N/A 

6.0 

9.8 

10.7 

Departure 

r N/A 

6.8 

8.8 

9.0 

Communication failure 

N/A 

N/A 

9.0 

^ 11.0 

Engine failure 

N/A 

N/A 

14.0 

14.0 

All nonemergency 

N/A 

6.4 

9.3 

9.7 


Table 5. Average Number of Total ATC Transmissions 
Per Run to Subject Aircraft 

Except for engine-failure scenario, all 
runs were approximately the same length 
in time and distance 


Scenario 

Transmissions per run and length 
of transmissions, sec, at — 

Data-link level 

1 

2 

3 

4 

Arrival 

22.3 

20.5 

17.6 

17.7 

Departure 

20.3 

21.6 

15.1 

14.0 

Communication failure 

N/A 

N/A 

10.0 

12.0 

Engine failure 

N/A 

N/A 

31.0 

26.3 

All nonemergency 

21.3 

21.0 

16.4 

15.6 





Table 6. Average Number of Pilot Voice Transmissions Per Run 
and Average Length of Transmissions 


Except for engine-failure scenario, all 
runs were approximately the same length 
in time and distance 


Scenario 

Transmissions per run and length 
of transmissions, sec, at — 

D.ata-link level 

1 

2 

3 

4 


21.3 

17.5 

7.4 

9.3 

Arrival 

and 

and 

and 

and 


2.5 

2.4 

2.7 

2.7 


22.8 

19.3 

9.5 

5.8 

Departure 

and 

and 

and 

and 


2.8 

2.7 

2.8 

2.7 




7.5 

5.5 

Communication failure 

N/A 

N/A 

and 

and 




2.6 

3.7 




15.0 

17.0 

Engine failure 

N/A 

N/A 

and 

and 




2.9 

2.8 


22.0 

18.4 

8.3 

7.3 

All nonemergency 

and 

and 

and 

and 


2.7 

2.6 

2.8 

2.7 



Table 7. Weather-Product Set 
[See ref. 10 for description of weather products] 


Pilot request 

Weather Product 

REQUEST DEPARTURE ATIS 

DEN DEP INFO DELTA, 1400Z WX 
CEILING 4 BKN 10 OVC, 

VIS 3L, WIND 340/8, 

ALT 29.92, TEMP 53/51, 

DEP RWYS 35L & 35R, 
CONTACT CLRNC DELIV 127.6 

REQUEST ARRIVAL ATIS 

DEN ARR INFO BRAVO, 1400Z WX 
CEILING 4 BKN 10 OVC, 

VIS 3L, WIND 340/8, 

ALT 29.92, TEMP 53/51, 

ILS 26L AND 35R IN USE 

or 

DEN ARR INFO ECHO, 1400Z WX 
CEILING 7 OVC, VIS 6, 

WIND CALM, ALT 29.92, 

TEMP 68/64, EXPT VECTORS 
ILS 26L 

or 

DEN ARR INFO FOXTROT 1500Z WX 
CEILING 8 OVC, VIS 10, 

WIND 350/5, ALT 29.92, 

TEMP 76/65 

ILS 26L AND 35R IN USE 

[ REQUEST PIREPS 

UA 1350Z B80 MOD RIME ICG AT 
12000 FT, 20 DME NORTH DEN 

" REQUEST SIGMETS 

SIGMET PAPA 1300Z 
MOD TO SVR ICG ABV 11 000 FT 
OVER CO, NE, KS 

REQUEST TERMINAL 

DEN FT 1200Z 

FORECAST 

C5 BKN 10 OVC 4R- 
3510G15, OCNL C2 OVC 1R 
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Table 8. Data-Link Message Set 


CLEARANCE ON REQ 

CLRD TO GLD AS FILED, 

MTN 8000 FT, EXPT 12 000 FT 
10 MIN AFTER DEPARTURE, 

DEP 128.05, SQUAWK 4324 

CLRD TO GLD AS FILED, 

MTN 10000 FT, EXPT 11000 FT 
10 MIN AFTER DEPARTURE, 

DEP 128.05, SQUAWK 5735 

CLRD TO GLD VIA 
V19 IOC V148 TXC V4, 

MTN 9000, 

DEP 123.85, SQUAWK 5263 

HOLD FOR LANDING TRAFFIC 

TAXI INTO POSITION & HOLD 

FLY RWY HEADING, 

CLRD FOR TAKEOFF 

CONTACT DEP 

CALL ATC ON • _ _ (Blanks contain a frequency 

assignment) 

VOICE COMM LOST 

STANDBY 

UNABLE 

CONTACT GROUND .9 WHEN CLEAR 
TAXI TO GA RAMP 

TURN RIGHT HDG (Blanks contain a heading 

assignment) 

TURN LEFT HDG 

FLY HDG . . . 
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Table 8. Concluded 


c & 

MTN . . 

FT 

D & 

MTN . 

FT 


RADAR CONTACT 

TRAFFIC, NUMEROUS ARRIVALS 
DEPARTING FLOTS SOUTHBOUND 
AT 11000 FT 

PROCEED DIR KIOWA 

FLY HEADING . . INTERCEPT 
DEN 118 RADIAL INBOUND 

FLY HEADING ....VECTORS 
TO FINAL APPROACH COURSE 

TURN RIGHT HEADING 120, 

INTERCEPT V4, RESUME OWN NAV 

CONTACT DEN CENTER 127.5 

CONTACT DEN APPR 120.8 

CONTACT APPROACH 125.3 

WIND 330/10, ALT 29.92 

FLY HEADING . . ., 

MTN 7200 FT TIL ON LOC, 

CLRD ILS RWY 26L, 

CONTACT TWR 118.3 AT THE OM 

FLY HEADING , 

MTN 7500 FT TIL ON LOC, 

CLRD ILS RWY 35R, 

CONTACT TWR 119.5 AT THE OM 

CLRD TO LAND 


(Indicates “climb and maintain” an 
altitude) 

(Indicates “descend and maintain” 
an altitude) 


(Blanks contain a heading 
assignment) 


(Blanks contain a heading 
assignment) 


(Blanks contain a runway specifica- 
tion, either 26L or 35R) 


GO AROUND 

IF ABLE, MTN 160 KNOTS 
TO THE OUTER MARKER 
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Table 9. Data-Link System Time Delay 



Time delay, sec, with— 


Clear screen 

Full screen 
(1-line messages) 

ATC transmit to 
cockpit 
annunciation 

Almost 0 

Almost 0 

ATC transmit to 
display in 
dedicated window 

0.5 

0.5 

ATC transmit to 
beginning of text 
writing 

0.7 

6.2 

Time required to 
write text: 



1-line message 

0.8 

0.8 

2-line message 

1.5 

1.5 

4-line message 

3.2 

2.9 

Time required to 
clear a full screen 


6.1 

Time required to print 
ATC page 

31 

31 

Weather: 



Time required to write 
weather-page menu 

7.5 

7.5 

Time from pressing “SEND” 
to finish writing ATIS 

5.6 

5.6 

Time to switch from 
weather page to display 
of full ATC page 

7.6 

7.6 

Buffer page: 



Time to switch from ATC 
page to display of full 
buffer page 

6.8 

6.8 


Time to return to and 
display a full ATC page 


7.6 


7.6 



Data-iink 
display and 
keyboard 



28 


ORIGINAL PAGE IS 
OF POOR QUALITY 


Figure 1. Instrument panel of Langley general-aviation simulator. 



ORIGINAL PAGE IS 
OF POOR QUALITY 
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Figure 2. Langley Controller Station for Mission-Oriented Terminal-Area Simulation Facility. 







^ L-86- 10,500 

Figure 3. Cockpit data-link display and keyboard. 


ORIGSKAi. F-A3E 

OF POOR QUALITY 
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Figure 4. Routes used in arrival scenarios. 
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CLRD TO OLD VIA 
VI 9 IOC VI 48 TXC VI, 

MTN 9000, 

DEP 138.85, SQUAWK 5263 
F I A' R W V I I E A D I N G , 

CLRD FOR TAKEOFF 
TURN LEFT HDG 130 


CONTACT DEP 


R E Q l J E S T C LEARA N C E 

HDG 130 IaLT f 9000 


Figure 9. Data-link level-4 display. 










Cl, HI) TO GLD AS FILED, 

MTN iOOOO FT, KXPT 1 I 000 FT 
l 0 Mil's AFTER DFPARTFRF, 

I) FT 128. 0 5 , S Q U A W Is A 7 ■ * A 

HOLD FOR LAND IN Ct TRAFFIC 
TAX 1 INTO POSITION AND HOLD 
FLY RWY 1 1 FADING, 

CLRD FOR TAKE OFF 


I IDG 2 AO 


alt : IOOOO 


Figure 10. Data-link buffer information display. 


r..Ao: is 

Of FGOit QUALITY 



MENU SELECT 


1 - AT IS DEPART 

2 — AT IS ARRIVAL 

3 — PIREPS 

4 - SIGMETS 

5 - TERM. FORECAST 















